feat(chrome): add native browser debugging tools - #7027

🖼️ web-shell visual preview

Rendered against a mock daemon (no real backend): the PR base vs this PR head c1bb688. Only screenshots that changed are shown (flows below, if any, are head-only) — refreshes on every push.

Screenshots · before / after

ℹ️ No screenshot changed against the PR base — but this PR edits 2 render-shaping files:

• packages/web-shell/client/components/WorkspaceSessionProvider.tsx
• packages/web-shell/client/main.tsx

Either the change has no visual effect (logic, plumbing, a state the scenarios never reach), or no scenario renders this UI — in which case the preview cannot see it, and an empty result is a coverage gap rather than a clean bill of health. To make it visible, add a scenario to packages/web-shell/client/e2e/visuals/screenshots.spec.ts that seeds whatever state the UI is gated on; it then appears here as a head-only (NEW) capture.

_{Full-resolution recordings (.webm) are attached to the workflow run.}

— Qwen Code · web-shell visuals

🩺 serve daemon A/B

Built the PR base vs this PR head c1bb688, drove a fixed endpoint set against each, and diffed the JSON responses. Only fields that changed are shown.

capabilities

health-deep-with-session

— Qwen Code · serve A/B

Thanks for the PR!

Template looks good ✓

Problem: This addresses a real workflow gap — browser automation today requires users to separately install and configure an external Chrome DevTools MCP adapter. Bundling it into the npm package creates security-scanner and release-compliance friction. The proposed solution (native tools in the Chrome extension, which already holds browser permissions) is a genuine improvement to the user experience. Refs #5626.

Direction: Aligned with Qwen Code's developer tooling mission. Moving browser tools into the extension eliminates an external dependency and simplifies setup. The pairing flow for daemon-extension trust is a reasonable security measure. No concerns about product direction.

Size: This is a large cross-package feature — ~3,330 production logic lines across 39 source files, ~2,810 test lines across 20 test files, and ~340 doc/plan lines. Core path touches are minimal (2 lines in packages/core/src/services/cronScheduler.ts). The bulk is in packages/chrome-extension/ (~2,635 lines) and packages/cli/src/serve/ (~870 lines). Per the 1000+ line advisory, the author may want to consider splitting if feasible, though the feature is cohesive.

Approach: The scope is large but focused — all changes serve the stated goal of native browser tools + pairing + ACP integration. The implementation plan in docs/plans/ shows deliberate design. No drive-by refactors or scope creep observed. Moving on to code review. 🔍

— Qwen Code · qwen3.7-max

_{Reviewed at 162707f684b7778b56c4f2a6a62ad936023c1759 · re-run with @qwen-code /triage}

Code Review

Independent proposal before reading the diff: to add native browser debugging tools to the Chrome extension, I'd implement a chrome.debugger-based CDP session manager with an MCP server that exposes tools (snapshot, screenshot, click, fill, navigate, evaluate, console, network) over the daemon's existing reverse MCP WebSocket channel. I'd add a pairing flow so random local processes can't claim the extension, and gate browser-tool invocation to extension-originated sessions only.

The PR's approach matches and exceeds this. The implementation is well-layered:

• ChromeDebuggerSession manages tab attachment/detachment with generation-based cancellation and a keepalive to prevent the service worker from being killed.
• BrowserTools implements 18 tools with thorough secret redaction (authorization, cookies, tokens, URL credentials) across all text paths — URLs, headers, response bodies, console output.
• BrowserMcpServer is a minimal JSON-RPC handler following the MCP protocol spec.
• The pairing flow uses HMAC-SHA256 with mutual proof, timing-safe comparison, rate limiting on failed attempts, and TTL-based code expiry.
• The bridgeClient.ts guard restricts qwen-browser-tools tool calls to sessions created by the paired Chrome extension (sourceType === 'default' && sourceId === 'chrome_extension').

No critical blockers or security issues found. The crypto is sound, error handling is thorough, timeouts are bounded, and the secret redaction covers all the paths I checked. Code follows project conventions — ESM, no any, tests collocated, proper TypeScript types.

One note: evaluate_script uses indirect eval via (0, eval)(...) which is correct for global-scope evaluation in a browser page context. The expression is safely transported through JSON.stringify.

Testing

Unit tests (826 tests, all passing):

packages/chrome-extension:
  browser-tools.test.ts       27 passed
  debugger-session.test.ts    11 passed
  server.test.ts               4 passed
  connection.test.ts           1 passed
  service-worker.test.ts       3 passed
  discovery.test.ts            7 passed

packages/cli:
  extension-pairing.test.ts    5 passed
  client-mcp-ws.test.ts       11 passed
  client-mcp-sender-registry  10 passed
  transport.test.ts          276 passed

packages/acp-bridge:
  bridge.test.ts             406 passed
  bridgeClient.test.ts        65 passed

Real-scenario testing (tmux): Not applicable for this PR. The feature is a Chrome extension that requires a real Chrome browser, extension installation, and interactive daemon pairing. The PR author has explicitly noted: "A final interactive Chrome smoke pass is still required before marking the PR ready." This can only be verified by a reviewer on macOS with Chrome installed.

— Qwen Code · qwen3.7-max

_{Reviewed at 162707f684b7778b56c4f2a6a62ad936023c1759 · re-run with @qwen-code /triage}

Confidence: 4/5 — Solid feature implementation with thorough test coverage and sound security design. The only gap is interactive Chrome testing, which requires a human reviewer with Chrome installed.

This PR does exactly what it says: moves browser debugging tools from an external adapter into the Chrome extension, using chrome.debugger and the daemon's existing reverse MCP channel. The pairing flow is a well-designed security measure — HMAC mutual proof, timing-safe comparison, rate limiting, and TTL-based expiry. The bridgeClient.ts guard that restricts browser tool calls to extension-originated sessions is a smart additional layer.

The implementation is well-layered (debugger session → tools → MCP server → connection), the secret redaction is comprehensive across all text paths, and the test suite (826 tests across 12 files) covers the full stack from extension service worker through daemon pairing to ACP bridge integration.

The only thing I can't verify in CI is the actual Chrome browser behavior — does the side panel pairing flow work smoothly, do the tools interact correctly with real web pages, does the debugger attachment/detachment handle edge cases. The PR author has explicitly flagged this: "A final interactive Chrome smoke pass is still required before marking the PR ready." That's honest and appropriate — a reviewer on macOS with Chrome can verify this.

Approving. The code is clean, the tests are green, and the feature solves a real user problem.

— Qwen Code · qwen3.7-max

_{Reviewed at 162707f684b7778b56c4f2a6a62ad936023c1759 · re-run with @qwen-code /triage}

Pushed bccba721bc72 for the Install dependencies failure (job 100668360590): error TS2339: Property 'set' does not exist on type 'ClientMcpSenderRegistry'.

ClientMcpSenderRegistry exposes claim(serverName, sender, owner): boolean (packages/cli/src/serve/acp-http/client-mcp-sender-registry.ts:100); packages/cli/src/serve/acp-http/client-mcp-sender-registry.test.ts:117 called reg.set(...). Changed the call to reg.claim(...).

Verified locally on the new head: npx tsc --noEmit -p tsconfig.json goes from 9 errors to 8, and npx vitest run src/serve/acp-http/client-mcp-sender-registry.test.ts → 13 passed.

The 8 remaining errors are pre-existing on this base, present before the change and untouched by the PR: src/config/top-level-options.ts(59,14), src/serve/run-qwen-serve.ts(5550,9), (6125,9), (6807,11), src/serve/server.ts(1182,7), src/utils/modelConfigUtils.ts(29,7), src/ui/utils/export/formatters/html.ts(8,10), src/peerMessaging/peer-messaging.test.ts(134,45).

Heads up on CI: the PR is mergeable=CONFLICTING, so GitHub did not start Qwen Code CI for bccba721bc72 — only Assign PR owner, PR self-report label, PR Force-Push Reminder and 🧐 Qwen Pull Request Review ran. The fix stays unverified on CI until the branch is updated from main.

Merged main (b5c7635ff983) into this branch as c151240dacb1 and pushed. The PR was mergeable=CONFLICTING, which is why GitHub never started Qwen Code CI on bccba721bc72; CI is running on the new head now.

Eight files conflicted, three of them with design weight:

• packages/cli/src/serve/acp-http/client-mcp-ws.ts — the same race, fixed two different ways. Main re-checks disposed after the provider round-trip and rolls the provider entry back without waiting; this PR waited for the in-flight add inside dispose() and handleUnregister. Main's a stale late-failing register cannot undo a newer register pins the reconnect shape — unregister, then register again while add pre-release: fix ci #1 is still in flight — and with the wait in handleUnregister those frames never complete, so the wait could not be kept. Resolved in favour of main's non-blocking shape, keeping this PR's !this.registrar.hasServer(server) guard so a registration that lands after an unregister frame still tears its own provider entry down. The PR's waits for an in-flight registration before disconnect cleanup asserts the superseded blocking design and was replaced by tears down a registration that lands after an unregister frame, which covers the guard.
• client-mcp-sender-registry.ts / client-mcp-ws.test.ts — main's session-scoped runtime MCP senders and this PR's bridge.preheat() are both live: serverScopes (main) and the preheat call before the registrar claim (this PR) both stay. Main's ClientMcpBridge gained addSessionRuntimeMcpServer and removeSessionRuntimeMcpServer, so both mocks that satisfies ClientMcpBridge now carry them.
• docs/users/qwen-serve.md — main's CORS bullet plus this PR's Chrome extension bullet.

packages/cli/src/serve/run-qwen-serve.test.ts (unioned imports), packages/cli/src/serve/routes/session.ts, packages/cli/src/serve/acp-http/client-mcp-sender-registry.test.ts and packages/web-shell/client/main.tsx (main's tree with this PR's extensionPairingCredential prop) are mechanical.

Local verification on c151240dacb1:

• npx vitest run src/serve/acp-http/client-mcp-sender-registry.test.ts src/serve/acp-http/client-mcp-ws.test.ts → Test Files 2 passed (2), Tests 39 passed (39)
• npx tsc --noEmit → 191 error sites, the same set as a clean origin/main worktree at b5c7635ff983, differing only in line shifts from the merged imports; no error is merge-authored.
• packages/web-shell npx tsc --noEmit → identical to origin/main except one error for extensionPairingCredential in WorkspaceSessionProvider.tsx. That field is added by this PR to CreateSessionRequest (packages/sdk-typescript/src/daemon/DaemonClient.ts:646) and is present in the merged source; the error comes from the stale packages/sdk-typescript/dist in the local worktree, which CI rebuilds.

Pushed 62821ccc382f: Integration Tests (no-AK, No Sandbox) failed on the merge head in qwen-serve-routes.test.ts:341:

- Expected
+ Received
@@ -130,13 +130,13 @@
     "workspace_archived_session_export",
-   "client_mcp_over_ws",
     "workspace_session_live_state",
     ...
     "session_worktree_reset_v1",
+   "client_mcp_over_ws",
     "voice_transcribe",

capabilities.ts advertises client_mcp_over_ws after session_worktree_reset_v1, and this PR's expectation — written before main added those workspace/session groups — still listed it ahead of workspace_session_live_state. Moved the entry to the served position.

Checked the whole expectation against the capabilities.ts key order: the 138 entries that appear in both are in the same order, 0 inversions. The pre-fix literal has exactly one inversion, the one CI reported.

Follow-up on the merge commit: two capability assertions in run-qwen-serve.test.ts still encoded the pre-extension defaults and failed deterministically (reproduced in isolation, not suite noise).

Root cause. This PR makes the daemon extension-ready by default in two ways:

• packages/cli/src/serve/run-qwen-serve.ts pins OFFICIAL_QWEN_CHROME_EXTENSION_ORIGIN into the effective allowOrigins list, so security.allowOriginMode is now specific instead of none.
• The same file treats a configured CDP adapter command as an active tunnel (cdpTunnelOverWs gains the cdpMcpCommandConfigured term, pinned by this PR's own new test enables the legacy CDP tunnel when its adapter command is explicitly configured), so browser_automation_mcp is advertised once QWEN_CDP_MCP_COMMAND is set.

does not advertise browser automation MCP without an active CDP tunnel passed /opt/qwen-cdp-mcp-adapter on a non-extension origin and asserted the capability stayed absent — under the new default that premise no longer holds.

Change (6b3cb8af1c18):

• That test now asserts the invariant it is named for with no tunnel signal at all: a http://localhost:5173 origin and no adapter command keeps browser_automation_mcp out of the envelope.
• reports bootstrap status and capabilities when fast path resolves on listen expects security: { allowOriginMode: 'specific' }, matching the pinned extension origin.

Both behaviour changes are deliberate in this PR and are covered by its own new tests; the two updated assertions were written before the extension defaults existed. Flagging them explicitly since allowOriginMode moves from none to specific for every daemon — the CORS list still contains only the official extension origin, so no operator-configured origin is widened.

Verification: npx vitest run src/serve/run-qwen-serve.test.ts — the six browser-MCP/tunnel/allow-origin tests pass; prettier --check clean. The remaining unrelated failures in that file also reproduce on clean main (runQwenServe telemetry validation, channel worker supervisor 26-owner cases).

The unit job on 6b3cb8af1c18 failed in four files. All of them reproduce at the branch's own pre-merge tip bccba721bc72 on the same machine, so they are not merge drift — they come from this branch, and ea7219e6d95d fixes them.

packages/chrome-extension/public/sidepanel.js — capability banner regressed

deriveWarning bailed out before consulting the capability model:

if (!features.includes('browser_automation_mcp')) {
  mcpProbeCounter = 0;
  cachedMcpSnapshot = undefined;
  return null;
}

deriveCapabilityStatus attributes "Browser bridge is disabled for this daemon." (no cdp_tunnel_over_ws) and the tunnel-only message from the feature list alone; the snapshot is only needed for the automation-* states. Returning null blanked the banner for every daemon without the legacy adapter feature, and sidepanel-assets.test.ts caught it (expected '' to be 'Browser bridge is disabled for this d…'). The guard now wraps only the /workspace/mcp probe, and the derivation runs in both branches.

The rest of that test file needed to follow the branch's new pairing contract: the fixtures now store a paired credential, answer the /extension/pairing/verify challenge the way a paired daemon does, render the #pair-form / #pair-code / .status__text elements the panel dereferences at load, and stub chrome.runtime.sendMessage (notifyDaemonReady).

packages/cli/src/serve/acp-http/transport.test.ts

The CDP cases mount the daemon without verifyExtensionPairingCredential, and the bridge presents no credential, so the extension-pairing gate rejected every connection before ensureChromeDevToolsMcpRegistered ran — that is why the earlier failures showed the "set QWEN_CDP_MCP_COMMAND" hint instead of the registering path. Those cases now wire a permissive verifier through startServer, which is what they are actually testing. The registered CDP MCP endpoint also carries the new tunnel token, so the assertion moved from the exact string to ws://127.0.0.1:${port}/cdp?access_token=.

packages/cli/src/serve/process-env-guard.test.ts

The new resolveCdpMcpCommand(process.env) read at the serve entry point is a second whole-object read; the allowance for packages/cli/src/serve/run-qwen-serve.ts goes from whole: 6 to whole: 7, with the reason string extended to say what the second read resolves.

packages/web-shell/client/main-boot.test.tsx

main.tsx now calls getExtensionPairingCredential(); the module mock did not export it, so the boot threw before mounting and both cases saw zero containers. The mock gains getExtensionPairingCredential: () => undefined, next to the existing getDaemonToken: () => null stub.

Verification

packages/cli      transport + client-mcp-ws + client-mcp-sender-registry + process-env-guard
                  Test Files  4 passed (4)      Tests  414 passed (414)
chrome-extension  sidepanel-assets.test.ts
                  Test Files  1 passed (1)      Tests  9 passed (9)
web-shell         main-boot.test.tsx
                  Test Files  1 passed (1)      Tests  2 passed (2)

The CI job on ea7219e6d95d agrees on the four files that used to fail:

✓ src/sidepanel/sidepanel-assets.test.ts (9 tests) 1244ms
✓ src/serve/acp-http/transport.test.ts (372 tests) 24213ms
✓ src/serve/process-env-guard.test.ts (3 tests) 1205ms
✓ main-boot.test.tsx (2 tests) 326ms

That attempt still ended with exit code 1: the step was Terminated for disk pressure (ENOSPC has failed test steps mid-suite while the host looks… in the workflow's own preamble, and the run uploaded disk-pressure-run-34713812121-attempt-1). It is a runner condition, not a test failure — no FAIL line appears anywhere in the job log. Attempt 2 is running.

No test was deleted or narrowed, and no other file's expectations were touched. ea7219e6d95d is pushed on top of 6b3cb8af1c18.

Correction to my previous comment: the nonzero exit of Test (ubuntu-latest, Node 22.x) on ea7219e6d95d was not the disk spike. It was a real failure in @qwen-code/web-shell, and it is fixed in 3939ad9ebc0e.

The job reported the workspace, but the failure had no FAIL line and no failing file summary, because vitest classifies a missing mock export as an unhandled rejection:

Unhandled Rejection
Error: [vitest] No "getExtensionPairingCredential" export is defined on the "./config/daemon" mock. Did you forget to return it from "vi.mock"?
 ❯ main main.tsx:367:38
    367|   const extensionPairingCredential = getExtensionPairingCredential();
 ❯ main.test.tsx:54:1

 Test Files  310 passed (310)
     Tests  7644 passed (7644)
    Errors  1 error
npm error Lifecycle script `test:ci` failed with error:
npm error code 1
npm error workspace @qwen-code/web-shell@0.23.3
npm error command sh -c vitest run --config vitest.config.ts --retry=2

main.tsx reads the pairing credential at startup, so every spec that mocks ./config/daemon has to expose it. main-boot.test.tsx was given the stub in ea7219e6d95d; main.test.tsx was missed, and its mock turned the read into an unhandled rejection that failed the workspace while all file and test counts still read as passed. The one-line fix adds the same stub:

 vi.mock('./config/daemon', () => ({
   getDaemonBaseUrl: () => '',
   getDaemonToken: () => 'token',
+  getExtensionPairingCredential: () => undefined,
   hasReloadSurvivableDaemonToken: () => testState.tokenSurvivesReload,

Evidence so far:

• cd packages/web-shell && npx vitest run client/main.test.tsx client/main-boot.test.tsx → Test Files 2 passed (2), Tests 20 passed (20), no unhandled error.
• Full web-shell suite (npx vitest run --config vitest.config.ts --retry=2, the CI command) ran locally on the fixed head: the summary carries no Errors 1 error line any more, so the unhandled rejection is gone. That run also had 46 App.test.tsx > App /goal command timing cases fail while a parallel full-workspace sweep was saturating the machine; those same files ran green in CI on ea7219e6d95d (310 files / 7644 tests, the only defect being this error), so they are contention artifacts, not a code change.
• On why the earlier ENOSPC theory was wrong: Terminated is the workflow's own disk-pressure sampler being shut down, and it appears on green main runs too (job 103614631806, lines 1037 and 28204), while the df -hT snapshot after the failed step showed the host healthy (/dev/nvme1n1p3 … 71%). The workspace exit code was the actual signal, and it was attributable to this repository's code.

Follow-up on the local web-shell noise I mentioned: it is pre-existing, not contention and not this branch. Running the same file on clean main (b5c7635ff983) in the same local setup gives the identical result:

# this branch (3939ad9ebc0e), packages/web-shell:
Test Files  1 failed (1)
      Tests  37 failed | 876 passed (913)

# main (b5c7635ff983), same command:
Test Files  1 failed (1)
      Tests  37 failed | 876 passed (913)

Identical counts on both trees, and CI on ea7219e6d95d ran that file green, so those App.test.tsx Goal cases are a local-environment artifact only. The fix for the actual failure stands: the missing getExtensionPairingCredential stub in packages/web-shell/client/main.test.tsx (3939ad9ebc0e).

The mock fix worked: the workspace phase is green on 3939ad9ebc0e, so test:scripts ran at the repo level for the first time — and that exposed a second real failure, in this PR's own packaging cases:

 FAIL  scripts/tests/chrome-extension-package.test.js > ... keeps the build script portable for Windows npm lifecycle runs
AssertionError: expected undefined to be defined        ❯ ...:34  expect(packageJson.devDependencies.archiver).toBeDefined()
 FAIL  ... > rejects forbidden stale entries in the final extension archive
TypeError: (0 , scanZip) is not a function              ❯ ...:59
 FAIL  ... > writes the package version into the built manifest
AssertionError: expected '0.23.3.65535' to be '0.23.3'  ❯ ...:117

Those cases were written against an earlier design that this PR superseded, and nothing caught it because the unit job never reached test:scripts (it aborted in the web-shell workspace). The shipped code is what it should be, so the cases are what I corrected in c1bb688665ac:

• packages/chrome-extension/scripts/package-extension.js packages with the POSIX zip binary — there is no archiver dependency to assert. The Windows-portability point of the case, that neither the build nor the package npm script embeds a shell-only construct, still holds and is still asserted.
• artifact-scan.js exports scanZipArtifact(zipPath, signatures), returning { file, signature } findings for archive entries; scanZip never existed. The case now builds a real zip and asserts the finding for a forbidden chrome-devtools-mcp reference.
• sync-extension.js writes the four-component Chrome version through toChromeManifestVersion, so the built manifest is 0.23.3.65535 by design (as manifest-version.test.js already pins). The case now compares against that helper instead of the plain package version.
• The last assertion looked for npm -w packages/chrome-extension run package in the root test:release script, which has never contained it; that command is the CI packaging step (.github/workflows/ci.yml:799), so the case now asserts it there.

Local run: npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/chrome-extension-package.test.js → Test Files 1 passed (1), Tests 4 passed (4).

Both fixes hold on c1bb688665ac. Test (ubuntu-latest, Node 22.x) now passes end to end: test:ci:workspaces completes — web-shell reports Test Files 310 passed (310) (line 27994 of the job log) with no unhandled rejection — and test:scripts runs to completion for the first time on this branch:

 ✓ scripts/tests/chrome-extension-package.test.js (4 tests) 84ms
 Test Files  86 passed (86)
      Tests  2461 passed | 12 skipped (2473)

Lint & Static, Integration Tests (no-AK, No Sandbox), both Desktop Shell jobs, SDK Java, Serve A/B, Web-shell Visuals and tui-parity are green on the same commit.